1. Field of the Invention
The present invention relates to presence technology for instant message service, and in particular, to a method and device for providing Quality of Service (QoS) control capability for a presence server and a presence system supporting QoS control.
2. Description of the Related Art
Presence technology is an important enabler for many kinds of applications. Presence technology is starting to appear in numerous applications other than instant messaging. For example, Microsoft Corporation is adding presence capabilities into applications such as Word, Excel, Outlook and others. IBM Corporation has added presence capabilities to Lotus Notes 7.0. It is likely that presence technology will be used more often in many different scenarios.
FIG. 1 shows a conventional Session Initiation Protocol (SIP)-based presence system. The presence system shown in FIG. 1 supports three primary operations: subscription, notification, and publication.
As shown in FIG. 1, the SIP-based presence system includes a presentity 103, a presence server 101 and a watcher (including a subscriber 105 and a fetcher 107). The presence server 101 is a core entity by which the presence technology can be implemented and it is is a functional entity which accepts, stores and distributes presence information, distributes watcher information, receives presence information from many presentities 103, and merges the presence information received from one or more presentities 103 into one single document according to the rules determined by an information model. In the case where the system can be managed and user privacy can be ensured, the fetcher 107 is allowed to inquire presence information actively or the subscriber 105 is allowed to subscribe presence information according to predetermined rules.
Subscribing to presence information service means to request the presence server 101 to automatically deliver some presence information concerned by users in some cases. Users can subscribe to each other. A user who delivers a subscription request is referred to as subscriber. A user who is subscribed to is called a subscribee.
FIG. 2 shows a present implementation structure of the presence server 101 based on the current J2EE architecture. Referring to FIG. 2, a SIP Servlet (Siplet) is shown. The Siplet is a set of APIs, which defines a set of high level extended APIs for a SIP server. The Siplet allows a SIP application to use a servlet model for deployment and management. It follows the JSR 116 specification. JSR is a standard organization of the Java community that incorporates manufacturers such as Sun, IBM, BEA and others and 116 is the serial number of the specification.
As shown in FIG. 2, the implementation structure of the presence server 100 is approximately divided into three layers from top to bottom.
The third layer is a SIP stack layer 250 which is responsible for the implementation of a SIP protocol, including network connection management, SIP message parsing and basic processing in a SIP transaction layer.
The second layer is a Siplet container layer 230 which is a module whose interfaces conform to industry standards and is used to provide the required support for running a Java Servlet, such as creating a servlet and maintaining its life cycle. Apache Tomcat and corresponding products of companies such as IBM, BEA, etc. are examples of a Java servlet container.
As shown in FIG. 2, the secondary layer includes the following units: a Siplet context management unit 226, a Siplet management unit 227, a message-Siplet relationship unit 228, a timer management unit 229 and a session/conversation management unit 231. They are the structural units included in the secondary layer of an existing typical J2EE architecture-based presence server.
Every unit shown in FIG. 2 is static in the case of non-runtime and there are no invocation relationships among them. Only after a user has defined the relationships among them as required, the invocations among these units will occur according to the definitions at runtime. Since the actual invocation relationships among these units have no particular impact on the implementation of the present invention, the description thereof is herein omitted.
The Siplet context management unit 226 can be implemented as a data structure which stores information on SIP messages and SIP transactions in a certain format.
The Siplet management unit 227 is a unit which performs runtime management on the Siplet such as creation, elimination and the like.
The message-Siplet relationship unit 228 is used for managing relationships between the included SIP messages and the Siplet. The message-Siplet relationship unit 228 associates the SIP messages with the Siplet supported by the first layer (i.e., the SIP application/presence application layer 210) based on the destination address included in the SIP messages.
The timer management unit 229 can be referred to as a clock service unit or as a timer management service unit. With interfaces provided by the unit, a timer event to be generated at a certain time or time interval is specified and an event monitor (an invoked method/function) can be registered for this event. When a Timer event occurs, this event monitor can receive notifications and corresponding methods/functions can be invoked.
Utilizing such a function provided by the Timer management unit 229, a developer can implement a periodically executed routine or a routine which is executed after a specific time period. Various versions for the implementation (for example, IBM, BEA, SUN, etc.) of J2SE (Java 2 Standard Edition) and J2EE (Java 2 Enterprise Edition) provide many kinds of clock service in different layers. For example, the basic standard library included in JDK has a clock service therein and the CommonJ criterion collaboratively provided by IBM and BEA also has a timer management service therein.
In a SIP protocol, session and conversation are two strictly defined concepts. Among other things, a conversation represents a peer-to-peer SIP relationship between communicating parties which lasts for a period of time. The life cycle of a typical conversation begins when the calling party dials and ends when either of the two parties hang up. The conversation is built by a SIP message such as a response to an INVITE request. The conversation is marked by an identifier, a local tag and a remote tag.
In the SIP protocol, a session refers, in particular, to a multimedia session. A multimedia session consists of a group of multimedia senders and receivers and data streams from senders to receivers. A multimedia conference is an example of a multimedia session. A session can include many conversations. While a conversation may relate only to two peer-to-peer parties, a session can relate to many parties.
From above definitions, a SIP application such as the presence server 101 can simultaneously maintain many sessions which correspond to sequences interacted with different users and correspond to many interactive sequences with the same user. The session/conversation management unit 231 is responsible for mapping incoming and outgoing SIP messages to sessions and conversations so that the messages can be processed by using the information of the sessions and conversations. For example, for an incoming SIP request message, in an attempt to match conversations, can be determined to see whether the message is a message initiating a session or a message in a session so that different processing routines can be used. For example, when the load is high, more resources will be used for completing an already started conversation rather than initiating a new conversation. As another example, for an outgoing message, a Siplet can simply ask to deliver a 200 OK response message even though the message is not complete. Through matching conversations, some routing information recorded in the conversation can be utilized to supplement message headers.
The first layer is a SIP application/presence application layer 210 which includes one or a group of SIP servlets that are responsible for implementing core functions of a presence server.
The interfaces among these three layers conform to industry standards. A Siplet interface is a primary interface between the first layer and the second layer. Each SIP message will be submitted to and processed by a certain Siplet. The Siplet implements the service logic of a presence server by processing SIP messages. The interface between the second and third layer is a JAIN interface. Both interfaces are API interfaces.
In an existing presence system, each incoming presence update (publication) will generate many notification messages to be sent to all watchers. Thus, for each presence update, outgoing network traffic and CPU utilization rate will be high. Currently, in a presence server having a typical structure shown in FIG. 2, (1) incoming messages are analyzed in the third layer, (2) the traverse passages provided in the second layer directly arrive at a SIP servlet in the first layer, and (3) outgoing messages directly arrive at the third layer through the passages provided in the second layer and are sent out by the third layer. In other words, this implementation structure does not consider the QoS requirement for various messages and the impact on CPU utilization rate. Further, an existing SIP-based presence server does not perform admittance control in order to prevent the CPU from overloading. Thus, the processing performance and QoS ensure capability of the presence server is very limited.
Sometimes, when the status of a presentity that has many watchers is changed, a lot of notification messages will need to be processed in a short time, resulting in peak CPU utilization. That will cause the CPU to overload and lose important messages in some situations. Different applications have different QoS requirements. For example, the response latency of an IP telephone can be several milliseconds, the response latency of instant messaging can be several seconds, and the response latency of presence-based collaborative applications can be several minutes.
In US patent application No. US2005/0105464A1 published on May 19, 2005 to Acharya, et. al., a method and system for differentiated processing of SIP messages to perform a VoIP call control is disclosed. In this patent application, SIP messages are assigned to different queues depending on the type of the SIP messages where each queue uses a different service rate. However, the patent application does not show implementation of the intermediate layer of the J2EE architecture-based presence server and the processing is only unidirectional.
In patent application No. WO06114135A1 published on Nov. 2, 2006 to Anders, et. al., a message processing method and apparatus used in an IP multimedia sub-system is disclosed. The patent application generally relates to a mechanism for interaction among many components in an IP Multimedia Subsystem (IMS) which allows a user to not be affected by a message with a low QoS requirement such as a presence message or an instant message at the time of performing an IMS application with a high QoS requirement, e.g. Voice over IP and Video over IP. The patent application proposes to record the start and end of SIP session with a high QoS requirement utilizing the network server (NS) so that an entity such as a presence server can utilize the information to delay the message delivery. Therefore, the patent application directed to ensuring the QoS of a high priority VoIP application and ensuring the performance of high priority VoIP application at the cost of a low priority application using the interaction among various units of IMS system. However, it does not ensure the QoS of presence server.